Phase: Acceptance And System Test

Acceptance test and system test

This phase describes the TMap life cycle model, with the associated activities, for the test levels acceptance test and system test. Both can actually be considered (and therefore organised) as autonomous processes. They have their own test plan, their own budget, and often their own test environment to execute the test. They are processes running parallel to the development process, which must be started by preference while the functional specifications are being created.

In the context of testing, the client is summarised as the accepting (demanding) party and the supplier as the delivering party. Each of these parties has its own responsibility in testing. The supplier executes the system test to determine whether the system complies with the functional and technical specifications. This demonstrates that everything that needs to be delivered is actually being delivered. After the supplier has executed the system test, reworked the detected defects and subjected them to a retest with a positive result, the system is offered to the client for acceptance. The accepting party wants to determine, with the test, whether what has been asked for is actually being delivered and whether it can do with the product what it wants to/must do.

TMap life cycle model

The process of the acceptance and system tests consists of a number of different activities. The TMap life cycle model is used to map the various activities, with their mutual order and dependencies. It is a generic model and can be applied for both test levels. However, the acceptance test and the system test each give their own interpretation to the life cycle model. In the TMap life cycle model the test activities are divided over seven phases (see figure 1 - TMap life cycle model). These are the phases Planning, Control, Setting up and maintaining infrastructure, Preparation, Specification, Execution and Completion.

Figure 1: TMap life cycle model

In the Planning phase, the test manager formulates a coherent approach that is supported by the client to adequately execute the test assignment. This is laid down in the test plan. In the Control phase the activities in the test plan are executed, monitored, and adjusted if necessary. The Setting up and maintaining infrastructure phase aims to provide the required test infrastructure that is used in the various TMap phases and activities. The Preparation phase aims to have access to a test basis, agreed with the client of the test, of adequate quality to design the test cases. The tests are specifi ed in the Specification phase and executed in the Execution phase. This provides insight into the quality of the test object. The test assignment is concluded in the Completion phase. This phase offers the opportunity to learn lessons from experiences gained in the project. Furthermore activities are executed to guarantee reuse of products.

The phases described above do not always have to be executed strictly sequentially. For instance, test cases for a part of the test may still be specified (Specification phase) while the test execution (Execution phase) has already begun for another part of the test. This is a situation that often occurs in projects in which there is phased delivery of software. We also recommend making preparations for the activities in the Completion phase as early as during the Specification phase. This phenomenon – where phases do not have to be executed sequentially - is expressed in the TMap life cycle model by the sloping lines between the phases. This results in the characteristic form of the model: the parallelogram.

When the life cycle model is related to the system development life cycle, a number of relationships come to light. Figure 2 - Relationship between TMap life cycle and system development life cycle shows an example of these relationships.

Figure 2: Relationship between TMap life cycle and system development life cycle

The figure shows that the preparation phase of the TMap test life cycle can start when the test basis is delivered. The test basis is created in the system development phases FD (functional design) and/or TD (technical design). After these system development phases, the realisation of the test object begins (the system development phase REAL). The test (TEST) starts as
soon as the test object is delivered. The next system development phase is the implementation phase (IMPL). This example demonstrates that only the TMap Execution phase is on the critical path of the project (the critical path is shown as a dotted line). All other test phases are executed in parallel to the other system development phases and, if ready in time, are not on the critical path.